Distributed measurement and control systems are often very complex involving multiple sensors and actuators (actuators convert electrical energy into mechanical motion) interacting with the system. A multistand printing press provides an example of such a system with multiple sensors and actuators. There are numerous motors, sensors, and controllers involved in adjusting the rotational speeds of the rollers for proper functioning of the press. The timing of such a system is critical to successful operation. Events or operations in each of the components must be time coordinated to achieve the desired synchronized motion for successful operation.
Similar timing requirements can be found in manufacturing systems, process control, robotics, and other industrial applications, such as paper converting and high-speed packaging machines.
Pure measurement applications often have precise timing requirements to enable successful correlation of the data. When there are many sensors involved, such as large-scale arrays for particle detection, vibration studies, and fault detection in telecommunications or power systems, timing requirements can be quite difficult to meet.
System architectures for meeting timing requirements may be divided into three categories: message based, cycle based and time based.
For message-based systems, timing is based on the time of receipt of a command or data message. FIG. 1 illustrates a typical prior-art measurement system with a central controller managing several sensors. For message-based systems, timing is based on the time of receipt
In many industrial applications, the direct communication to the sensors is managed by a programmable logic controller (PLC), with the resulting data communicated to a supervisory controller or an operator workstation. In machine control applications, such as robotics, packaging, etc., the sensors are often tied directly into the system controller without an intervening PLC. Similarly, in laboratory environments, communication is directed to the host processor, which typically is a personal computer (PC) running some sort of real-time operating system.
Returning to the specific prior-art example of FIG. 1, two sensors are shown communicating to a PLC via a bus, such as one of the controlled-area network (CAN) based buses and two other sensors are directly wired into the PLC, one directly to an input-output (I/O) module and the other via a serial link. In a laboratory or data acquisition configuration, sensor data communication is often directed to the PC with no intervening PLC. This is typically via a direct link, such as RS-232 or a bus such as IEEE-488.
In message-based systems, the controller typically polls each of the sensors by sending a command or message to the sensor. In a polled system, sensor timing is based on the time of receipt of this message from the controller. Thus, the temporal properties of the program executing in the PLC or PC, the communication latency in the I/O links to the sensor, and any latency in the sensor itself establish the time of sensing.
Message-based systems work very well when the required timing accuracy is not extreme, the timing schedule is simple, and intersample intervals are easy to meet given other application requirements. Timing accuracy is limited by fluctuations in the communication link, the operating system, the sensor, and the accuracy to which the latency can be measured. Such systems limit flexibility because closely spaced measurements are either difficult or impossible, depending on the characteristics of the computing environment, communication links, and the particular application. Simultaneous sensing is impossible in a pure message-based polling system unless some sort of global execution trigger is provided, for example, the group trigger function of IEEE-488.
For cycle-based systems, sensor and actuator timings are based on a periodic schedule typically established either as part of the communication link or the architecture of the controller application. For example, FIG. 2 illustrates a measurement system with a central controller managing several sensors and using a cyclic bus such as ControlNet or IEEE-1394.
Motion control applications often use cyclic control based on the serial real-time control system (SERCOS) bus, as illustrated in FIG. 3. In this case, the PLC communicates update values to the servo-drives via the SERCOS bus.
Cyclic systems are not a good match for applications in which the sampling intervals must be changed during operation in a way not commensurate with the original interval. Once established, the cycles can be very repeatable and accurate, but the process of changing cycle period and definition during normal operation is not trivial. Also, the amount of data sent during the interval is limited by the duration of the interval. And most cyclic networks like SERCOS support only the grandmaster-slave type of communication, while many modem control applications require support of peer-to-peer communication.
For time-based systems, sensor sampling, actuator timing, and initiation of critical control code are based on triggering the specified actions referenced to the time of a real-time clock rather than on message receipt, interrupts, or as a consequence of the speed of execution of control code. The highest accuracy is achieved if the real-time clock is local to the device implementing a specific trigger (FIG. 4).
Weak coupling between system timing and message generation/delivery in time-based systems provides system designers additional freedom in meeting system requirements. The general computing environment based on a common sense of time established using the network time protocol (NTP) exploits this weak coupling. NTP targets large distributed computing systems with millisecond synchronization requirements. The protocol proposed in this standard specifically addresses the needs of measurement and control systems: spatially localized, microsecond to submicrosecond accuracy, administration free, and accessible for both high-end devices and low-cost, low-end devices.
Correct operation of such a system depends on the real-time clocks being synchronized to their peers with sufficient accuracy to meet the application requirements. In this system, the timing accuracy of the various events in the system is a function of the accuracy to which the local real-time clocks are synchronized, as opposed to the determinism of the communication links and application program execution as in the other timing methods. Application program execution in the controller and communication latency is still an issue but only insofar as the specification of the event or the time-stamped data arrives before it is needed. That is, arrival time must precede the actual time of execution. This is a much looser requirement than requiring that the arrival time be coincident with the time of execution.
In a distributed system, the local clocks may be synchronized via a protocol, such as IEEE 1588.
IEEE 1588 specifies a protocol for synchronizing real-time clocks in networked systems of distributed components characterized by: relatively compact systems of perhaps a few subnets; minimal use of network bandwidth, node computing, and memory resources devoted to clock synchronization; low administration overhead; and low-end and low-cost devices.
The protocol uses networks supporting multicast communications including but not limited to Ethernet. Because of the increased use of Ethernet in measurement and control environments, Annex D of IEEE 1588 specifies the mapping to User Datagram Protocol/Internet Protocol (UDP/IP) on Ethernet.
FIG. 5 illustrates typical components and topology for an Ethernet-based distributed system. Each leaf or node component, such as a sensor, actuator, or controller, includes a clock synchronized through the IEEE 1588 protocol. Attached to a router are subnets A and B. Each of the subnets consists of a switch or repeater connected to several of the clocks. The router also includes a boundary clock defined in the IEEE 1588 specification.
The protocol defines a grandmaster-slave hierarchy of synchronization. The protocol will automatically select one clock in each subnet to be the subnet grandmaster, and one clock in the system to be the system grandmaster, termed the grandmaster. Selection is based on properties of each clock, such as stability and accuracy on the topology of the network.
In motion control systems it is also well known to determine patterns of the motions of motor systems using graphic software. The patterns are then used for controlling the motor systems. However, such patterns have not been effectively applied to distributed time synchronized systems.
It would be desirable to use pattern s with distributed autonomous control systems for multi-axis motion control.